fix(layer): ship the native addon versions dd-trace declares - #857

What does this PR do?

Makes the layer ship @datadog/pprof and @datadog/native-appsec at the exact versions declared by the dd-trace it bundles, instead of at datadog-lambda-js's own devDependency pins.

• scripts/move_ddtrace_dependency.js now takes the installed dd-trace package.json. It reads the dd-trace version and the two native addon versions (from dd-trace's optionalDependencies) from that file. The build fails with a clear error if dd-trace stops declaring either addon, instead of silently falling back to a stale pin.
• Dockerfile passes node_modules/dd-trace/package.json to the script.
• integration_tests_local/prepare-layer.js (and its README) does the same, so the local layer fixture keeps matching the release layer.

Motivation

profiling would be broken if we release a layer now.
Why it breaks?

1. dd-trace starts sending "auto". dd-trace v5.128.0, v6.17.0 and master default DD_PROFILING_EXPERIMENTAL_OOM_HEAP_LIMIT_EXTENSION_SIZE to "auto" (dd-trace-js #10348) and pass it to pprof. Only pprof 5.19.0 and later understand "auto": their heap-profiler.js turns it into 0 plus a flag. dd-trace declares @datadog/pprof: 5.20.0, so its own code is correct.
2. The layer build swaps in an older pprof. pprof is an optionalDependency of dd-trace. The datadog-lambda-js Dockerfile installs with yarn install --ignore-optional, then ships its own hand-maintained pin, "@datadog/pprof": "5.18.1". That pin matches the dd-trace 6.15.0 that main releases today. Your benchmark layer swapped in dd-trace master but kept the old pin.
3. dd-trace turns the error into "no profiling at all". Profiler.start() catches the error, sets #startFailed, and stops every profiler permanently. It only logs this when DD_TRACE_DEBUG is on, which is why the info-level logs looked clean.

This pin has broken in both directions before. It started as "*", which drifted ahead of dd-trace, was then pinned to 5.14.4 (#783), and has now fallen behind dd-trace. Taking the versions from dd-trace removes the second source of truth.

Testing Guidelines

The script's output for each dd-trace manifest:

• Error paths: a missing dd-trace argument, and a dd-trace manifest that doesn't declare @datadog/pprof, both fail with a descriptive error.

• prepare-layer.js against the installed tree writes dd-trace 6.15.0, pprof 5.18.1 and native-appsec 11.0.2 to deps.package.json.

• The layer Docker build for every Node version runs in this PR's CI ("Build Layers for System Tests" and the GitLab layer build and size check).

• End-to-end on Lambda nodejs26.x (serverless-e2e-tests test_profiling_usage, staging org): I built this branch's layer with dd-trace bumped to 6.22.0, which defaults to "auto" and declares pprof 5.20.0. The build pulled in pprof 5.20.0 and native-appsec 11.0.3. With no env overrides, across 22 invocations:

  • all three profilers started, with no uint32 errors;
  • the profile was accepted by intake.profile.datad0g.com;
  • datadog.profiling.agent reported, and test_profiling_usage[node26-profiling] passed.

  The same test against a layer bundling pprof 5.18.1 (built against dd-trace master) produced no profiles.

Additional Notes

• Changes released layer contents at the next release: native-appsec 11.0.1 → 11.0.2, matching dd-trace 6.15.0. pprof is unchanged (5.18.1).
• The @datadog/pprof and @datadog/native-appsec devDependencies stay as they are for local development and unit tests. They no longer decide what ships in the layer.
• Layers built by other pipelines that bypass this Dockerfile (for example, ones that copy a dd-trace checkout over node_modules) aren't covered by this change.
• A follow-up hardening idea for dd-trace (not needed for this fix): catch a failing OOM-monitor setup in NativeSpaceProfiler.start so it disables only OOM monitoring, not all profiling.

Types of Changes

• Bug fix
• New feature
• Breaking change
• Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

• This PR's description is comprehensive
• This PR contains breaking changes that are documented in the description
• This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
• This PR impacts documentation, and it has been updated (or a ticket has been logged)
• This PR's changes are covered by the automated tests
• This PR collects user input/sensitive content into Datadog
• This PR passes the integration tests (ask a Datadog member to run the tests)

🤖 Generated with Claude Code